🟠 High Adapters/ClaudeAdapterV2.ts:3829

ClaudeAdapterV2Driver.create reads ProviderContinuationRequests from the context, but this is a Context.Reference whose default drops all offers. In production, providerAdapterRegistryLayerFromProviderInstances does not provide providerContinuationRequestsLayer, so the driver receives the default sink. Every Claude adapter then stores offer: () => Effect.void, and all background-task wake turns are silently dropped instead of reaching ProviderContinuationService — the continuation mechanism never runs outside tests. Make the production registry layer provide providerContinuationRequestsLayer, or change the driver to require a non-default implementation so the missing provider fails loudly instead of silently dropping work.

In file @apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts around line 3829:

`ClaudeAdapterV2Driver.create` reads `ProviderContinuationRequests` from the context, but this is a `Context.Reference` whose default drops all offers. In production, `providerAdapterRegistryLayerFromProviderInstances` does not provide `providerContinuationRequestsLayer`, so the driver receives the default sink. Every Claude adapter then stores `offer: () => Effect.void`, and all background-task wake turns are silently dropped instead of reaching `ProviderContinuationService` — the continuation mechanism never runs outside tests. Make the production registry layer provide `providerContinuationRequestsLayer`, or change the driver to require a non-default implementation so the missing provider fails loudly instead of silently dropping work.

🟡 Medium

releaseIfStillIdle reuses the stale pinnedSinceMs when re-arming the idle timer after deferring for pending background work. Activity paths that go through touchActivity or markIdle (e.g. respondToRuntimeRequest, steerTurn, interruptTurn, or provider events) never reset pinnedSinceMs — only markBusy clears it. So a session that had pending work, then later receives fresh activity without ever becoming busy, will still carry the original pin timestamp. The next idle check sees now - pinnedSinceMs >= maxIdlePinMs and immediately releases the session, even though it had recent activity and still reports pending background work. Resetting pinnedSinceMs to null in touchActivity would clear the stale pin on fresh activity.

In file @apps/server/src/orchestration-v2/ProviderSessionManager.ts around line 712:

`releaseIfStillIdle` reuses the stale `pinnedSinceMs` when re-arming the idle timer after deferring for pending background work. Activity paths that go through `touchActivity` or `markIdle` (e.g. `respondToRuntimeRequest`, `steerTurn`, `interruptTurn`, or provider events) never reset `pinnedSinceMs` — only `markBusy` clears it. So a session that had pending work, then later receives fresh activity without ever becoming `busy`, will still carry the original pin timestamp. The next idle check sees `now - pinnedSinceMs >= maxIdlePinMs` and immediately releases the session, even though it had recent activity and still reports pending background work. Resetting `pinnedSinceMs` to `null` in `touchActivity` would clear the stale pin on fresh activity.

🟡 Medium orchestration-v2/ProviderContinuationService.ts:56

The worker loop permanently drops a continuation request whenever dispatchContinuation fails. requests.take removes the item from the queue, but the Effect.catchCause handler only logs the failure and never retries or re-enqueues it — so the buffered provider wake event is lost and never ingested as a run. This is reachable via the queue_after_active dispatch path, which rejects dispatch while a thread has pending merge-back transfers. Consider re-enqueuing the request (or retrying with backoff) before logging so the wake event survives a transient rejection.

In file @apps/server/src/orchestration-v2/ProviderContinuationService.ts around line 56:

The worker loop permanently drops a continuation request whenever `dispatchContinuation` fails. `requests.take` removes the item from the queue, but the `Effect.catchCause` handler only logs the failure and never retries or re-enqueues it — so the buffered provider wake event is lost and never ingested as a run. This is reachable via the `queue_after_active` dispatch path, which rejects dispatch while a thread has pending merge-back transfers. Consider re-enqueuing the request (or retrying with backoff) before logging so the wake event survives a transient rejection.

Also found in 1 other location(s):
- apps/server/src/orchestration-v2/ProviderSessionManager.ts:44 -- Using the new `RELEASE_SCOPE_CLOSE_TIMEOUT_MS` causes `releaseEntry`/`close()` to report success after 30s even when `Scope.close(entry.scope, Exit.void)` later fails. Once `Effect.timeoutOption(...)` returns `None`, the code only logs the eventual `Exit` in a detached observer and never re-raises it as `ProviderSessionReleaseError`/`ProviderSessionCloseError`, so callers cannot detect adapter cleanup failures anymore on any close path that finishes after the timeout.

🟡 Medium orchestration-v2/ProviderContinuationService.ts:42

dispatchContinuation discards the providerThreadId and driver from the ProviderContinuationRequest, dispatching a generic message.dispatch against the thread's current routing. If the thread's active provider changes before the worker drains the request (e.g. after a provider switch or handoff), the synthetic wake turn starts on the wrong provider thread while the buffered provider-native wake messages remain attached to the original provider thread and are never ingested. Consider passing request.providerThreadId and request.driver through to threads.dispatch so the continuation targets the correct provider.

In file @apps/server/src/orchestration-v2/ProviderContinuationService.ts around line 42:

`dispatchContinuation` discards the `providerThreadId` and `driver` from the `ProviderContinuationRequest`, dispatching a generic `message.dispatch` against the thread's current routing. If the thread's active provider changes before the worker drains the request (e.g. after a provider switch or handoff), the synthetic wake turn starts on the wrong provider thread while the buffered provider-native wake messages remain attached to the original provider thread and are never ingested. Consider passing `request.providerThreadId` and `request.driver` through to `threads.dispatch` so the continuation targets the correct provider.

🟡 Medium

When a session has pending background work, releaseIfStillIdle calls scheduleIdleReleaseInternal, which immediately calls cancelIdleFiber(entry.idleFiber). Because entry.idleFiber still points to the currently running idle-release fiber, the fiber interrupts itself and then joins its own interruption, deadlocking forever. Any session that defers idle release for pending background work will wedge instead of rescheduling. Consider passing cancelIdleFiber: false to the reschedule path (or skipping the cancel when the current fiber is the idle fiber) so the self-interrupt does not happen.

In file @apps/server/src/orchestration-v2/ProviderSessionManager.ts around line 673:

When a session has pending background work, `releaseIfStillIdle` calls `scheduleIdleReleaseInternal`, which immediately calls `cancelIdleFiber(entry.idleFiber)`. Because `entry.idleFiber` still points to the currently running idle-release fiber, the fiber interrupts itself and then joins its own interruption, deadlocking forever. Any session that defers idle release for pending background work will wedge instead of rescheduling. Consider passing `cancelIdleFiber: false` to the reschedule path (or skipping the cancel when the current fiber is the idle fiber) so the self-interrupt does not happen.

Idle release stale pending check

High Severity

releaseIfStillIdle decides not to defer when hasPendingBackgroundWork is false, then calls releaseEntry without re-checking pending work. Wake output can land in the adapter buffer after that read but before the session is torn down, so idle release can drop a live Claude session while wake messages and a queued continuation are still in memory.

 

^{Reviewed by Cursor Bugbot for commit 90e67c3. Configure here.}

Pending work errors imply none

Medium Severity

When hasPendingBackgroundWork fails, releaseIfStillIdle treats the session as having no pending work via Effect.catchCause(() => Effect.succeed(false)), so idle release can proceed while wake buffers or background tasks may still be active.

 

^{Reviewed by Cursor Bugbot for commit 90e67c3. Configure here.}

Failed continuation blocks retry

Medium Severity

When a wake is detected, the Claude adapter records the native thread in requestedContinuations before enqueueing a continuation request. If ProviderContinuationService later skips or fails dispatch (for example archived thread, orchestration error, or logged dispatch-failed), nothing clears that flag or sends another request. Further wake output stays buffered, hasPendingBackgroundWork remains true, and the wake may never run until idle pin expiry or session release.

 

^{Reviewed by Cursor Bugbot for commit 90e67c3. Configure here.}

Dropped continuation blocks wake retry

Medium Severity

When the continuation worker skips or logs-and-swallows a failed message.dispatch (for example an archived thread), the Claude adapter still keeps requestedContinuations set and wake data buffered. No second continuation is offered, so wake output may never be ingested until idle pin expiry tears down the session.

 

^{Reviewed by Cursor Bugbot for commit fc4490c. Configure here.}

Continuation ignores wake provider thread

Medium Severity

Wake continuation requests carry providerThreadId, but dispatch only passes threadId into message.dispatch, so the orchestrator binds the run to activeProviderThreadId. If that differs from the thread that owns the buffered wake session, the continuation run opens the wrong provider session and the wake buffer is never drained.

 

^{Reviewed by Cursor Bugbot for commit fc4490c. Configure here.}

Stale background task registry

Medium Severity

pendingBackgroundTaskIds is only cleared when a task_notification is handled on an active turn. Wake output buffered outside a turn (including a terminal result without a replayed notification) never removes those IDs, so hasPendingBackgroundWork can stay true after the wake is ingested and idle release is deferred until the pin cap on every idle cycle.

 

^{Reviewed by Cursor Bugbot for commit fc4490c. Configure here.}